Java is an object oriented programming language developed by Sun Microsystems, Inc.. Similar to C++, Java is smaller, more portable, and easier to use than C++ because it is more robust and it manages memory on its own. Java was also designed to be secure and platform-neutral (meaning that it can be run on any platform) through the fact that Java programs are compiled into bytecode, which is not refined to the point of relying on platform-specific instructions and runs on a computer in a special software environment known as a virtual machine. This characteristic of Java makes it a useful language for programming Web applications, since users access the Web from many types of computers. Java is used in programming small applications, or applets, for the World Wide Web, as well as in creating distributed network applications.
Java Beans are a Java component of architecture defined in the JavaBeans specification developed by Sun Microsystems (Sun). A JavaBean, or Bean, is a reusable application component—an independent code segment—that can be combined with other JavaBean components to create a Java applet or application. The JavaBean concept emphasizes the platform independence of the Java language, in which ideally a program, once written, can run on any computing platform. JavaBeans are similar to Microsoft's ActiveX controls. ActiveX controls, however, can be developed in different programming languages but executed only on a Windows platform. JavaBeans can be developed only in the Java programming language but ideally can run on any platform.
Enterprise Java Beans (EJB) are an application programming interface (API) designed to extend the JavaBean component model to cross-platform, server-sided applications that can run on the various systems usually present in an enterprise environment. Enterprise Java Beans are defined in the Enterprise JavaBean Specification released by Sun Microsystems, Inc. The goal of the API is to provide developers with a means of applying Java technology to the creation of reusable server components for business applications, such as transaction processing. An Enterprise Java Server (EJS) hosts the EJBs.
The EJB specification grew out of the Common Object Request Broker Architecture (CORBA) specification in which pieces of programs (objects) communicate with other objects in other programs, even if the two programs are written in different programming languages and running on different platforms. A CORBA program makes its requests for objects through an Object Request Broker (ORB), and thus does not need to know the structure of the program from where the object comes. CORBA is designed to work in an object oriented environment. As used herein, Object-Oriented (OO) means of, pertaining to, or being a system or language that supports the use of objects. Object, as used herein, means (in object-oriented programming) a variable comprising both routines and data that is treated as a discrete entity. The EJB specification enforced a set of standards, allowing customers to develop, in Java, completely portable server-side components independent of any one vendor's implementation.
EJBs are different from the original Java Beans. The original JavaBeans specification was geared toward enabling a variety of user interface components to be combined to produce a stand alone application (such as a stock tracking application that contains a small spreadsheet, a pie chart, and a perhaps a few other user interface components). The EJB specification is geared toward enabling distributed, transactional, secure, scalable, portable, reusable business components that allow server side components to be developed, that leverage an existing framework for addressing enterprise business concerns.
According to the EJB specification, there are two types of beans. The first type are Session Beans and the second type are Entity Beans. Session beans are generally “coordinator” type beans. Session Beans have no identity and are temporary objects whose primary purpose is to control the entity beans. Entity Beans are the beans whose data gets persisted to a database. Only Entity Beans have keys, and only Entity Beans have finder methods on their homes.
There are two types of Entity Beans. The first type is a Container Managed Persistence Bean (CMP). The application server takes care of persisting a CMP's data to the database, so that the developer doesn't have to write any code to interact with the Java Data Base Connectivity (JDBC) API (which defines a standard way of accessing a relational database from a Java Application) or any other database persistence technology. CMP is the generally recommended approach, because it is easier, and it lets the developer leverage any special capabilities of the application server, such as caching, optimistic locking, or others. The second type is a Bean Managed Persistence Bean (BMP), which requires the developer to take care of all database persistence logic. BMP is used only when the developer needs to talk to some database that the developer's application server does not support, or when the developer has other special persistence needs. CMP Entity Beans are the only type of beans where the application server gets involved in a query; therefore, further references to beans herein shall be defined as CMP Entity Beans.
The strength of the EJB spec is the framework that allows users to focus on writing code to implement their business logic, without having to worry about writing “plumbing” code such as code to persist data to a database, code to enforce security (like verifying userIDs, encrypting communciation, etc.), code to coordinate transactions, code to manage workload distribution to improve scalability, etc. The “plumbing code” is taken care of by the EJS, per the EJB specification, enabling EJBs to run on many different vendor's application servers (avoiding proprietary solutions).
In a few places in the EJB specification, Sun decided to leave it up to each vendor to decide how to implement a certain functionality, so that different vendors could come up with different solutions that allow them to differentiate themselves in the marketplace. One such place is Query (also called “Custom Finder Support”)—the EJB spec simply says that, since different application servers can implement the ability to find EJBs in different ways, part of the EJB deployment process is to solicit input from the deployer as to how custom finder methods are to be implemented for the target EJB application server. Deployment is the process of taking the portable EJB and generating the necessary vendor-specific code (referred to as “Tie” code). Based on an analysis of that EJB, the Tie is generated to allow the EJB to run in a particular vendor's application server. Thus, each vendor is required to implement their own form of finder support, and to gather any necessary data from the deployer about the specific details needed to implement each custom finder method on a bean's home.
For example, an Account EJB, per the EJB spec, has a public interface that specifies the attributes of a given account (such as account number, account Holder name, and account balance), and which operations a client can invoke on a given account (such as debit, credit, transfer, and determineAvailableFunds). It also has a home interface, which specifies how a client can create a new account or find an existing account. The EJB framework requires all homes to have a findByPrimaryKey operation, which locates an instance of a specified account based on its key value, such as an account number. The EJB framework requires all persistent EJBs to have a key, which is used to uniquely identify a given instance of an EJB. Any other methods for finding an EJB, or a set of EJBs, are referred to as custom finder methods. For instance, an Account's home might also have a findLargeAccounts method, which would perform a query that finds all accounts with a balance equal to or greater than a specified amount. It would be up to the EJB deployer to specify how to perform such a query when deploying the bean to a given vendor's application server. Most application servers simply have the user specify a query using regular SQL, where the query is formed in terms of a database table name and its Column names. Moreover, most application servers require the developer to wait until deployment time to specify the implementation of the developer's custom finder methods, and such implementations require a database administrator (DBA) to tell the developer various details about how the data handled by the EJB is persisted.
Therefore, a finder helper is needed that does not require changes if the database structure changes. The finder helper needs to be portable and not specific to a given database layout. One solution meeting these needs would be a more powerful form of query expressed in object-oriented terms, where the query is formed in terms of EJB home names and EJB attribute values allowing a “finder helper” to be coded up front at EJB development time.
For example:    EJB attributes: accountNumber, accountHolderName, accountBalance    EJB methods: debit, credit, transfer, determineAvailableFunds    EJB home methods: create, findByPrimaryKey, findLargeAccounts    table name holding EJB data: ACCT    table column names: ID, CUST—NAME, ACCT—BAL
Most app servers would require the developer to implement the findLargeAccounts( ) method in a vendor-specific, database-specific way, by supplying a string such as “select * from ACCT a where a.ACCT—BAL>1000”. The EJB deployer (who probably knows very little about the bean or how it is persisted) would be required to know how to come up with this string, by consulting with their DBA. EJBs are portable and reusable, meaning you can take off-the-shelf beans and make use of them in your enterprise. EJBs can provide a finder helper which contains an object-oriented query that doesn't require any foreknowledge of what database table schemas will be used. This portable, OOSQL query would be in terms of the bean's attributes. For example, a query could be written as “select ref a from Account a where a.accountBalance>1000”. The developer could provide this info at development time, in terms of the bean's attributes, and such info would be portable—that is, not tied to a specific persistence implementation decided by a DBA.
A further need exists for the portable SQL query. EJBs are Object-Oriented, and all objects have attributes (called instance data) and operations (called methods). Most vendors only allow queries over attributes. However, in OOSQL, you can also perform queries that involve invoking operations. In the Account example, a method called determineAvailableBalance( ) was listed. Often banks require a depositor to maintain a certain minimum balance, meaning the finds available for withdrawal may be less than the current balance. For instance, the depositor may have a balance of $1100, but your balance is not allowed to fall below $250, meaning the available balance is only $850. Thus the determineAvailableBalance( ) method is enforcing a business rule. With non OO queries, the deployer would have to know this business rule and enforce it by modifying their SQL query to be “select * from ACCT a where a.ACCT—BAL-250>1000”. A need exists for a solution where the developer can provide a finder helper class with the beans, which would contain an OOSQL query like “select ref a from Account a where a.determineAvailableBalance( )>1000”. OOSQL allows the developer all methods (which might perform any arbitrarily complex function), whereas SQL only lets the developer deal with the values of particular columns in a table that stores the bean's attributes. Therefore, a need exists for a solution which produces a portable, OOSQL query in terms of the bean's attributes and methods.
An exemplary embodiment of this invention is provided in Component Broker (CB), a member of the WebSphere Application Server, Enterprise Edition (WAS/EE) suite of products. CB is a CORBA based application server with EJB support. Before the advent of EJBs, CB hosted CORBA objects implemented in either C++ or Java, and provided a framework very similar to the EJB spec, called the Managed Object FrameWork (MOFW). IBM contributed heavily to the EJB spec, incorporating many of the concepts originally introduced in the MOFW. One portion of the MOFW allows for OOSQL query to be performed over the homes of CORBA objects. The present invention leverages this query functionality, bridging the CORBA and EJB worlds by enabling EJBs to leverage the query capabilities of the MOFW. Other embodiments of the invention can leverage whatever query capabilities are provided by the given application server.
To keep this invention portable (and not proprietary to WAS/EE), all of the bridging logic is encapsulated in a base class from which the desired finder helper class would inherit. To further simplify this process, a code generation tool is provided, which emits the “boiler plate” code for a finder helper class, based on examination of the home for the desired object. The developer can then simply fill in the appropriate OOSQL strings. It is important to note that such a finder helper would be portable—other app servers could make use of the finder helper by providing their own implementation of the base class containing the bridging logic specific to the particular application server.